home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
526-550
/
disk_542
/
pp
/
pp.doc
< prev
next >
Wrap
Text File
|
1992-05-06
|
12KB
|
291 lines
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Powerpacker Patcher
Version 1.3
Copyright (C) 1991, Michael Berg
All Rights Reserved
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
INTRODUCTION
Ever got tired of having to use PPMore or equivalent to view all those
Powerpacked datafiles you have scattered everywhere? Or maybe PPMore
doesn't do exactly what you want?
Well, this program should solve your problem. It makes PowerPacker
datafiles look completely like normal files. In fact, there is now not one
thing you can do with normal files, which you cannot do with PowerPacker
files.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
RUNNING PP
Powerpacker Patcher runs from either the Workbench or the CLI. If you
use it from CLI, you need not RUN it, because it detaches itself from the
current CLI process as soon as it is activated.
If you run PP "as is", with no arguments, it will use RAM: for its
background file decrunching. You may supply PP with one argument,
describing the path it should use instead. Harddisk users with limited
memory will probably welcome this.
It is possible for you to specify PP's temporary path from the
Workbench, too. Click (down,up) on PP's icon. Then press and hold either
SHIFT button, and double-click (2*(down,up)) on the disk or drawer icon to
be used for background file decrunching. PP will let you know if you made
a mistake during startup.
Once Powerpacker Patcher has installed itself in AmigaDOS, it will
display a small banner message to show you that everything went all right.
Powerpacker datafiles will begin to "act" as normal files as soon as PP
has been activated. Most programs, commercial or PD, will be fooled into
thinking that a powerpacked file exists in the form of its decrunched
state. When they attempt to load such a file, the decrunched version of
the file will be passed along to the program.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
STOPPING PP
Simple! Just re-run PP and the in-memory version will terminate
immediately. DOS will be restored to its original state, and Powerpacker
datafiles will again appear as ... Powerpacker datafiles!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
SAMPLE APPLICATIONS
Well, what is it all good for, then? Here's a small list just to get
your juices flowing:
o Viewing Powerpacker datafiles (text)
Simply use the TYPE command - or bring the text directly into
your favourite editor (TxEd, CygnusEd)
o Viewing Powerpacker datafiles (pictures)
Crunch a typical IFF picture. Then bring it directly into
DPaint or equivalent
o Icons
Yes, that's right. Go ahead and crunch all those icons. Workbench
will never know the difference. Remember to retain the names of
the icons - DON'T use ".info.pp". Workbench recognizes icons
as files with a postfix of ".info".
o Include files (header files)
Why not go ahead and crunch all your include files for your
compiler?
o Much more
There is no end to it. ANY kind of datafile may now be crunched,
because it will retain its functionality 100% as long as PP is
up and running. Script files for AmigaDOS, *.config files for
programs that support config'ing, *.doc files for public domain
disks, IFF pictures for DPaint, rexx scripts, makefiles, sound
samples, printer drivers -- YOU NAME IT!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
THEORY OF OPERATION
It's simple, really. PP juggles with a few DOS library vectors, so that
future calls to certain DOS functions will be rerouted through PP. When a
file-open request arrives, PP looks at the file in question in order to
determine the filetype. If it is a special file (e.g. CON: or NIL:) a
filehandle from the original DOS Open() function is returned. Otherwise,
the file is decrunched to a memory block, which is then flushed into a
temporary file on the RAM disk or in the directory you supplied PP with
when you started it. A pointer to this new file is then returned.
You might think that the path for temporary files would be crowded with
files in a very short time, but PP is intelligent enough to remove them as
they are no longer needed. If PP sees that the temporary file has been
changed between the Open and the Close call, the file is rewritten over the
original file, if possible.
Future attempts to Examine() a powerpacker datafile will return the size
of the decrunched file in the FileInfoBlock, and not the size of the
Powerpacker datafile itself. Why? Imagine an editor trying to load a text
file. It does an Examine() to get at the filesize. Then it allocates just
enough memory to hold the file. It then loads the file into that memory
area. Well, that just won't work if the filesize it receives from
Examine() is about 50% too small. Keep in mind that as soon as an Open()
attempt is made, the file is decrunched, and will thus have a completely
different filesize!
For further details on the technique involved, please read the
sourcecode -- it's included for just that.
You will probably notice that the program is all in one piece. I am
profoundly against "handlers". This barbaric dissection of programs can
make everything much more confusing and your L: directory a heck of a lot
more crowded. Techies will argue, that the reason for splitting your code
in a startup and a resident (the handler part) module is obvious; this way
only relevant code stays in memory and the startup code terminates at once.
Well, the startup code part is rarely much more than a few K, and I
myself gladly sacrifice that small an amount of memory, if this means that
I don't have to copy two files for every executable I have. Handler code
is only for *exceptional* programs, where NO OTHER solution seems
acceptable.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
CAVEATS
Yep, there are a few of these, too. First of all, you have to remember
that PP is a one way street. This means that loading Powerpacker files
will work fine, but saving them again will result in a non-crunched file.
The powerpacker.library sorely lacks a crunch function.
Secondly, when working with crunched icons (or, for that matter, any
other type of crunched file), there is a nominal performance reduction
caused by the decruncher. Don't expect icons to pop up at the same rate as
they used to, or include-files to get included as fast as they used to.
Use of B.A.D. or Addbuffers is recommended.
Thirdly, the DOS library patches aren't done according to the textbook
(if there is one on this topic!). If you skim through the source, you
won't find any calls to SumLibrary(). Its presense or absense seemed to
make no difference whatsoever, so I left it out (what does it do, anyway?).
Up until version 1.1 of PP, it would crash on a 2.0 machine. This has
now been fixed, and PP should be able to run on *any* Amiga. The program
was tested on an A500 using AmigaDOS 1.2, with .5Mb extra RAM fitted, but
has also undergone testing under AmigaDOS 2.0.
The overall effect of this program is quite astonishing. I use it all
the time. Try it - it is just fantastic to see how *.pp files act as if
they were completely normal files!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
KNOWN BUGS
Erm.. none, as far as I can tell. However, don't try to remove PP's
temporary directory while it is still running (direct invitation to the
Guru dude).
Further, there seems to be a small bug in the Aztec autodetaching
startup code. If you use PP in your S:Startup-Sequence, it appears that
you should either RUN or RUNBACK pp, or else the EndCLI will not close the
CLI window. I am working on this problem, and will probably find a way
around this using an arp compatible autodetach startup module (if I can
find one!)
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
REMAKING PP
I've enclosed a makefile suitable for Matt Dillons "DMake". The
makefile should be used "as is" only if you want PP to be autodetaching.
If you don't, remove all references in the makefile to the macro STARTUP.
This means removing the definition of the macro, and removing the
"$(STARTUP)" from the line that activates the linker (the "ln" line).
Also, you must find the definition of the C macro DETACHING in the
sourcecode. It's located somewhere around line 53. A non-detaching
version of PP would have this definition commented out.
That's really all there is to it. Oh, by the way, remember to set
CCOPTS to nothing before issuing the DMake command (the DMakeFile handles
parameters for CC on its own). PP will then be remade using large code,
large data & 32 bit integers. Large code & data, because other processes
will be executing internal procedures in PP, which is virtually impossible
using the small memory model. ( Sure it's possible, but I'm lazy! |^) )
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
THANKS GO TO...
Well, who other than Nico François. Nico's powerpacker.library, and,
for that matter, all the other powerpacker tools, are simply brilliant.
Credit where credit is due!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
FUTURE RELEASES
Version 1.0 of PP was pretty much a beta release, and 1.1 didn't
support all you 2.0 guys & girls. This version (1.3), however, should be
free of nasty surprises. There's still a multitude of possibilities for
improving PP. Some obvious choises:
o More control on PP. Switching PP temporarily on and off while it
is running.
o Option to specify multiple paths for file decrunching, such that
if one fills up, the next will be used.
o Maybe build in a screen blanking facility or PopCLI style
hotkeys for starting a new CLI. Will this be useful, or will
it merely interfere with the real PopCLI? Let me know.
o Patching more DOS functions. DeleteFile() is a good one. This
would enable to the user to verify the "dangerous" actions of
a new program (a small autorequester: "ARE YOU SURE (blabla)").
o More on this: Turning PP into a simple virus protector as well.
o Anything else that YOU would find useful!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
SHAREWARE
PP is shareware. If you remember, this means that I would really like a
small donation if you use it alot. $5+ will get you the next version of
PP, as soon as it is available.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
FLAMES
If you find anything you (dis)like, mail me. You're gonna have to write
to me actually using old-fashioned ink and paper, because I'm not yet in
the modem business. If you can't remember how to hold a pen, get one of
the tribe elders to show it to you. Anyway, here's my address:
Michael Berg
Sct. Peders Gade 24A, 2th
8900 Randers
DENMARK
(I expect to purchase a modem shortly, so be prepared for some real havoc
on all those BBS's 8^) )
Have fun!
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
__
///
__ ///
\\X// AMIGA - Quite Simply the Best Computer Ever.
¯¯¯
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨